I'll fix the typos check soon

I can see that GitHub's file changes view shows only one file at a time due to the large number of changes. This is because the reference implementation includes dependencies and auxiliary materials:

• The reference code uses secp256k1lab python library (vendored as a git subtree, ~20 files) for scalar and group arithmetic. I can remove this from the PR when the library is integrated into this repository (RFC: Integrate secp256k1lab v1.0.0 as subtree, use it for BIP-374 #1855).
• Auxiliary files include docs/partialsig_forgery.md (which I can move to a gist if preferred) and a test vector generation script (~1400 lines). I can exclude these if necessary.

If you can motivate some other reviewers meanwhile, that would also be welcome.

I've shared it with most of the Bitcoin cryptographers I know and will post it on Twitter and the Bitcoin dev groups I'm part of. Hopefully that will bring in more reviewers!

Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Yes, it's a .md issue, this bip initially had a manually written table of contents but was removed after #2070 (comment)

As I mentioned on X i'm working on this, so you will likely see more comments in the future. Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Click there. ;)

As I mentioned on X i'm working on this, so you will likely see more comments in the future. Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Click there. ;)

Thank you! TIL :-)

@DarkWindman thanks a lot for the review! I've addressed most of your review comments in a88f033.

Let’s call this BIP 445. Please add an entry for your proposal in the README table, in the preamble update the BIP header to 445 and Assigned header to 2026-01-30, and update your documents file name as well as the auxiliary file directory.

I think the BIP should cite https://eprint.iacr.org/2024/436.pdf because it proves that Taproot and BIP 32 tweaking are secure.

Addressed the review comments and added the test vector coverage suggested in #2070 (comment). The only thing still open there is vectors for multiple threshold (t, n) configs, which is next on my list.

I also went over the spec and reference code again and fixed a few more mismatches.

I've added multiple (t, n) configs to the test vectors. They now run across 4 configs, (2,3), (1,3), (3,3), and (3,5), instead of the single (2,3) setup we had before. That takes the total from 68 to 250 cases. Here's the per-API breakdown:

nonce_gen and nonce_agg don't depend on (t, n), so they stay the same. The rest grew because they now cover all 4 configs.

I also re-read the BIP text and the reference spec and fixed a few inconsistencies.

As far as I can tell, this addresses all the open review comments. I think the BIP is good to merge once the other reviewers are happy with it.

@siv2r: Okay cool, I resubscribed to the PR and have added it to my review queue.

The changelog is at 0.6.0, using the same semver-style scheme as BIP327.

BIP327 bumped to 1.0.0 when its number was assigned. I didn't follow that for 445 because it was still under active review with suggestions coming in, so tagging it 1.0.0 felt premature back then. It's now had a good stretch of review without any drastic changes suggested.

@murchandamus should this be bumped to 1.0.0 just before merge? And what's the usual convention for bips changelog versioning?

@siv2r: Version 1.0.0 is usually reserved for the stage of the BIP that is advanced to Complete. You can find more guidance on Changelog Section and Version Header in BIP3.

@siv2r: It sounds like you think it’s ready for publication, some reviewers have indicated the same. Let’s merge this in a week (on or after July 6th) unless more things crop up. Or if you want it published before then, please let me know.

Let’s merge this in a week (on or after July 6th) unless more things crop up

Sounds good! I'll do one final review this week, and will update here if anything comes up. Else we can merge on July 6th.

Sorry for being late with a comment of this kind, but I think this should somehow take into account the "plausible attack on adaptive security of threshold Schnorr signatures" by Elizabeth Crites and Alistair Stewart (paper, talk).

tl;dr of the paper:

• The result of the attack (if possible, see caveats below) is that the attacker can forge a signature after compromising (and learning the secret shares of) fewer than t participants.
• It is not clear if there is an attack. It's only plausible in the sense that the attacker needs to solve a new computational problem from which nobody currently knows whether it's hard or not. This is unlike, e.g., the discrete logarithm problem on elliptic curves which has been studied for a long time, so that there's reasonable belief that it's hard.
• The attack requires the attacker to be adaptive, i.e., the attacker chooses whom to corrupt after seeing the results of key generation including the public shares. This is realistic; and I think users expect that the scheme remains secure if the attacker can do this.
• The attack requires t and n to be large. For example, a 131-of-196 setup is supposed to be easier to break than simply computing the discrete logarithm of the threshold public key but a 86-of-128 setup won't be affected (see Table 1 in the paper). Concretely, the authors suggest that the attack would be beneficial if effort(n, t) < 128 whereas effort is defined as in this Python code for secp256k1.

  from math import comb, log2
  def effort(n: int, t: int) -> float:
      c = comb(n, t-1)
      return -log2(c / ((2**256) + c))

The big question, of course, is what to do. I think there are two reasonable options:

1. Forbid affected parameters (n, t) entirely, and explain the rationale.
2. Only add a warning.

I tend to think that option 1 is better. Of course, that's a restriction in practice, but we can't just move on and pretend that everything will be fine. If someone wants to ignore the restriction, they can still do this, but then they're on their own.

Given these new review comments, I expect that we will not publish today. I’ll wait for your input, @siv2r.

After consulting with @elizabeth-crites, I have a clearer understanding now, and I should have mentioned also a second paper of her with Jonathan Katz, Chelsea Komlo, Stefano Tessaro, and Chenzhi Zhu (talk; immediately after the other talk in the same video).

In fact, the situation is better than I mentioned. It's not just that we don't know whether an attack exist.

The new paper defines a computational problem LDVR and proves that FROST is adaptively secure when LDVR is hard in addition to the discrete logarithm problem DL (or strictly speaking, its variant AOMDL). Then the paper proves that LDVR is – at least for parameters we're interested in (i.e., small enough n) – so hard that it's better for the attacker to attack DL instead.

Here's improved script that estimates the bit security (function effort) of an attack against LDVR. Here, t_c is the number of actually corrupted parties, i.e., the worst case is t_c = t.)

from math import log2, perm

BITS_GROUP_ORDER = 256

def myperm(n: int, k: int):
    if k >= 1:
        return perm(n, k)
    else:
        return 1

def table1(n: int, t: int, t_c: int | None = None):
    if t_c is None:
        t_c = t  # worst case
    return log2(myperm(n, 2 * t_c - t)/myperm(t_c, 2 * t_c - t))

# Check some numbers from Table 1 in https://eprint.iacr.org/2025/1061
assert table1(128,  96,  round(0.9 *  96)) -  79.24 <= 0.01
assert table1(256,  64,               64 ) - 203.57 <= 0.01
assert table1(1024, 512, round(0.6 * 512)) - 197.18 <= 0.01

def effort(n: int, t: int | None = None, t_c: int | None = None):
    if t is None:
        t = n // 2  # worst case
    return -(table1(n, t, t_c) - BITS_GROUP_ORDER)

DL has an (assumed) bit security of ~128, and to be on the safe side, we want that breaking LDVR is at least as hard, i.e., effort should return at least 128. So to determine safe parameters, the BIP could use rely on the effort function.

There's a cruder but much simpler restriction: As long as n <= 131, we'll always have effort >= 128. So a simple restriction (or recommendation) for the BIP could be simply to require n <= 131 (or maybe n <= 128 to be on the safe side and have a nicer looking number).

I'm pretty sure that 128 parties will be enough for all envisioned currently envisioned use cases of FROST.

@siv2r: Please let me know whether you want to go forward with the publication or are still making further updates. The recent review comments could also be addressed in a follow-up authored by another contributor.

I'm working on fixing the recent review comments. Let's not publish until they're fixed.